<HTML
><HEAD
><TITLE
>Compressed backups</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
"><LINK
REL="HOME"
TITLE="The Linux System Administrator's Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Backups"
HREF="backups.html"><LINK
REL="PREVIOUS"
TITLE="What to back up"
HREF="x2705.html"><LINK
REL="NEXT"
TITLE="Keeping Time"
HREF="c2732.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Linux System Administrator's Guide: Version 0.7</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x2705.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 12. Backups</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="c2732.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN2717"
>12.7. Compressed backups</A
></H1
><P
> Backups take a lot of space, which can cost quite
	a lot of money.  To reduce the space needed, the backups
	can be compressed.  There are several ways of doing this.
	Some programs have support for for compression built in; for
	example, the <TT
CLASS="OPTION"
>--gzip</TT
> (<TT
CLASS="OPTION"
>-z</TT
>)
	option for GNU <B
CLASS="COMMAND"
>tar</B
> pipes the whole backup
	through the <B
CLASS="COMMAND"
>gzip</B
> compression program, before
	writing it to the backup medium.  </P
><P
> Unfortunately, compressed backups can cause trouble.
	Due to the nature of how compression works, if a single bit is
	wrong, all the rest of the compressed data will be unusable.
	Some backup programs have some built in error correction, but no
	method can handle a large number of errors.  This means that if
	the backup is compressed the way GNU <B
CLASS="COMMAND"
>tar</B
> does
	it, with the whole output compressed as a unit, a single error
	makes all the rest of the backup lost.	Backups must be reliable,
	and this method of compression is not a good idea.  </P
><P
> An alternative way is to compress each file separately.
	This still means that the one file is lost, but all other files
	are unharmed.  The lost file would have been corrupted anyway,
	so this situation is not much worse than not using compression
	at all.  The <B
CLASS="COMMAND"
>afio</B
> program (a variant of
	<B
CLASS="COMMAND"
>cpio</B
>) can do this.  </P
><P
>	Compression takes some time, which may make the backup program
	unable to write data fast enough for a tape drive.
	
		<A
NAME="AEN2730"
HREF="#FTN.AEN2730"
>[1]</A
>
		
	This can be avoided by buffering the output (either internally, if
	the backup program if smart enough, or by using another program),
	but even that might not work well enough.  This should only be
	a problem on slow computers.  </P
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN2730"
HREF="x2717.html#AEN2730"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>If a tape drive doesn't data fast enough,
		it has to stop; this makes backups even slower, and can
		be bad for the tape and the drive.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x2705.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="c2732.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>What to back up</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="backups.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Keeping Time</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>